REMARKS 



Claims 1-62 were previously canceled. Claims 63-77 are pending. 

Claims 63 -77 were rejected under 35 USC 103(a) based on US Patent 6,859,830 to 
Ronneburg et al. and US Publication 2002/0032787 by Overton et al. Applicants respectfully 
traverse this rejection, based on the following. 

According to claim 63, the real management server, based on the performance data for the 
first real application server and the real data- source server, automatically determines that the first 
real application server is functional but has reached a predetermined upper level of utilization. 
The performance data for the real data- source server indicates an amount of utilization of the real 
data-source server in providing application data to one or more of the real application servers in 
the pool. The real management server selects the real data-source server to provide application 
data for an additional real application server and sends connection settings for the real 
data-source server to the additional real application server. Ronnenburg et al. and Overton et al. 
in combination do not teach or suggest these features of claim 63. 

Ronnenburg et al. disclose a server pool where each server in the pool is responsible for 
monitoring the up or down status of two "buddy" servers, based on responses to pings sent to the 
buddy servers. If a "buddy" server does not respond to the ping, it is removed from the server 
pool. A new server can be added to the pool by announcing itself to a server table. After being 
added to the pool, it is assigned buddies whose status it checks. 

"A virtual ring structure. In the virtual ring structure, each server is only required to 
monitor the status of two other servers in the serve pool. Thus, a server need only 
transmit ping signals to two other servers (its buddies) in the server pool at any given 
time. Because each server maintains the status of only two other servers at any given 
time, the size of the server pool is not limited by the ability of each server to send and 
process ping signals." Ronnenburg et al. Column 2 lines 8-17. 
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"The server table maintains a list of each "live" server and the buddy servers assigned to 
that server. Down servers are removed from the server table, and thus, the server pool, by 
use of the server table within the SQL server, [sic grammar] When a server determines 
that one of its buddies is down, the report to the SQL server results in a buddy 
reassignment. The buddies of the down server are made buddies of one another and the 
virtual server ring is established. The SQL server then knows not to route any client to 
the down server." Ronnenburg et al. Column 2 lines 25-33. 

"When a server is to be added to the server pool, another buddy reassignment is required. 
In such a case, a server and its buddy will be reassigned the added server as a buddy. 
Thus, the added server will have the original server and the buddy server as its buddies." 
Ronnenburg et al. Column 2 lines 34-39. 

"FIG. 3 is a flowchart illustrating a method 300 for adding a new server to the virtual 
server ring in accordance with an embodiment of the present invention. The method 300 
begins at start step 305 and proceeds to step 310 when a new server announces itself to 
the server table 135. Typically, on server start-up, the new server announces itself to the 
server table using an ADO ("Active Data Objects") call to ServerAnnounce, passing the 
new server's IP address as an argument. ADO is a programming interface that is designed 
by the Microsoft Corporation of Redmond, Washington as a standard for data access, 
which allows a client to interact with a SQL server, such as the Web server 1 10. In the 
preferred embodiment of the present invention, the ServerAnnounce stored procedure is 
stored on the Web server 110. The method proceeds to step 315. At step 320, the 
buddies of the new server are returned to the new server by the return mechanism of the 
call to the ServerAnnounce procedure. At this point, the new server becomes responsible 
for looking after these buddies." Ronnenburg et al. Column 5 lines 15-38. 
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While Ronnenburg et al. determine whether each server is functional based on the pings, 
Ronnenburg et al. do not disclose or even suggest that a real management server determines that 
a first real application server is functional but has reached a predetermined upper level of 
utilization. Ronnenburg et al. do not determine the performance of the first real application 
server based on the performance data for the first real application server and performance data 
for the real data-source server. (This determines whether slow performance of the first real 
application server is due to CPU constraint of the first real application server or delays in the real 
data-source server furnishing data to the first real application server needed to comply with the 
client request to the real application server.) Ronnenburg et al. do not even mention real 
data-source servers that supply data to the real application servers; rather, Ronnenburg et al. are 
only concerned with one "level" of server. Also, Ronnenburg et al. do not disclose or suggest 
that a real management server selects a real data-source server for a real application server added 
to the pool, nor that the real management server sends connection settings for the real data-source 
server to the additional real application server to configure the additional real application server 
to send subsequent requests for application data to the real data-source server. Ronnenburg et al. 
fail to disclose these key functions of a management server. Overton et al. do not fill these gaps 
of Ronnenburg et al. 

Overton et al. disclose that a client makes a request to a system to identify the location of 
a data repository containing data of the client, and the system responds with the identity of the 
data repository so the client can contact the data repository directly, 

"In a networked environment where there are a large number of data repositories and any 
particular entity does not have data in all of the data repositories, a mechanism is needed 
that would permit queries to be directed only at data repositories with relevant 
information. It would also be beneficial to permit membership in the set of data 
repositories itself to be highly dynamic. Such a system would support on-the-fly addition 
and removal of data repositories from the topology of a distributed database seamlessly 
and without the need to reprogram the database." Overton et al. Paragraph [0006] 
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"A system for managing location information and providing location information to data 
location queries comprises a transfer protocol configured to manipulate an identifier, and 
at least one location associated with the identifier, wherein the identifier uniquely 
specifies an entity and wherein each data location specifies a location of data in a network 
pertaining to the entity. The system also includes a location server containing location 
information corresponding to at least on entity that is formatted according to the transfer 
protocol, wherein the location of data relates to an application server in the network. The 
system further includes programming logic stored on the location server that is responsive 
to a location query identifying a desired entity to return a location message. The location 
message includes one or more locations associated with the desired entity." Overton et al. 
Paragraph [0008]. 

"The method includes receiving a location query from a client requesting the location of 
data relevant to an entity identified in the query. The queried location server sends a 
location response message to the client if the queried location server contains information 
relevant to the entity identified in the query. The location server sends a redirect message 
to the client if it does not contain location information relevant to the entity identified in 
the query, where the redirect message comprising a list of location servers containing 
information relevant to the entity identified in the query." Overton et al. Paragraph 
[0009]. 

"When a client queries the network distributed tracking protocol ("NDTP") server for 
information pertaining to an entity, the NDTP server preferably returns a list of all 
locations for the specified entity. The client then can directly access the various 
locations, relieving the NDTP server of any further involvement in the transaction and 
allowing the NDTP server to handle more queries." Overton et al. Paragraph [0040] 
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Thus, Overton et al. are concerned with identifying to a client/requestor the location of a data 
repository containing data of the client, so the client can contact the data repository directly to 
access the data. But this is unrelated to identifying a backend data-source server that provides 
data to an application server added to a pool. In contrast to claim 63, Overton et al. do not 
determine performance data for a functional computer. Overton et al. do not disclose or even 
suggest that a real management server determines that a first real application server has reached a 
predetermined upper level of utilization, based on the performance data for the first real 
application server and performance data for the real data- source server, where the performance 
for the real data-source server indicates an amount of utilization of the real data-source server in 
providing application data to one or more of the real application servers in the pool. Overton et 
al. do not disclose or suggest that a real management server selects a real data-source server for a 
real application server added to the pool, nor that the real management server sends connection 
settings for the real data-source server to the additional real application server to configure the 
additional real application server to send subsequent requests for application data to the real 
data-source server. Therefore, the rejection under 35 USC 103(a) based on Ronnenburg et al. 
and Overton et al. should be withdrawn. 

Claims 64-67 depend on claim 63, and therefore, distinguish over Ronnenburg et al. and 
Overton et al. for the same reasons that claim 63 distinguishes thereover. 

Claim 64 further distinguishes over Ronneburg et al. and Overton et al. by reciting that in 
response to the first real application server reaching a predetermined upper level of utilization, 
the real management server automatically sends to the additional real application server port 
settings for the real data- source server to communicate with the real data- source server to obtain 
application data from the real data-source server. Neither Ronnenburg et al. nor Overton et al. 
teach or suggest this feature of claim 64. 
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Claim 67 further distinguishes over Ronnenburg et al. and Overton et al. by reciting that 
in response to the first real application server reaching a predetermined upper level of utilization, 
the real management server automatically sends to the additional real application server a 
description of an installation path for the real data-source server to support communication with 
the additional real application server. Neither Ronnenburg et al. nor Overton et al. teach or 
suggest this feature of claim 67. 

Independent claim 68 distinguishes over Ronnenburg et al. and Overton et al. for the 
same reasons that claim 63 distinguishes thereover. 

Claims 69-72 depend on claim 68 and therefore, distinguish over Ronnenburg et al. and 
Overton et al. for the same reasons that claim 68 distinguishes thereover. 

Claim 69 further distinguishes over Ronnenburg et al. and Overton et al. for the same 
reasons that claim 64 further distinguishes over Ronnenburg et al. and Overton et al. 

Claim 72 further distinguishes over Ronnenburg et al. and Overton et al. for the same 
reasons that claim 67 further distinguishes over Ronnenburg et al. and Overton et al. 

Independent claim 73 distinguishes over Ronnenburg et al. and Overton et al. for the 
same reasons that claim 63 distinguishes thereover. 

Claims 74-77 depend on claim 73 and therefore, distinguish over Ronnenburg et al. and 
Overton et al. for the same reasons that claim 73 distinguishes thereover. 

Claim 74 further distinguishes over Ronnenburg et al. and Overton et al. for the same 
reasons that claim 64 further distinguishes over Ronnenburg et al. and Overton et al. 

Claim 77 further distinguishes over Ronnenburg et al. and Overton et al. for the same 
reasons that claim 67 further distinguishes over Ronnenburg et al. and Overton et al. 
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Based on the foregoing, Applicants request allowance of the present patent application as 
amended above. 



Respectfully submitted, 



Dated: February 1 . 2010 
Phone: 607-429-4368 
Fax: 607-429-4119 



/Arthur J, Samodovitz/ 
Arthur J. Samodovitz 
Reg. No. 31,297 
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